home *** CD-ROM | disk | FTP | other *** search
- «MDNM»Introduction
- PC Magazine LAN Benchmark README.TXT File
- ------------
-
- The PC Magazine LAN benchmark program is used to evaluate LAN
- hardware and software. This file provides an overview of the
- test programs and instructions on how to use them. The following
- sections are included in this document:
-
- LAN Test Overview
- How to Run the Tests
- Cleaning Up and Filenames
- PC Labs Setup
- How We Interpret Results
-
- You can write or call PC Labs at (212) 503-5570 if you have
- comments, suggestions, or questions.
-
-
-
- LAN Test Overview
- -----------------
- The PC Magazine LAN benchmark test provides a way to impose a
- consistent load on a LAN and to time specific procedures. The
- tests generate repeatable results, which can then be compared
- with other similarly configured LANs with the same number of
- workstations.
-
- The following captions are printed in PC Magazine when LAN test
- results are reported. They provide an overview of the three
- types of file loading used in the tests.
-
- The PC Labs LAN benchmark tests are written in C and are
- independent of commercial software. We ran the tests on a test-
- bed of five 8-MHz IBM PC ATs. For our test-bed to better
- simulate the conditions on a medium-size network of 20 or more
- workstations, we have designed these loading tests so that a
- single station represents five to ten times the load of a user
- performing an interactive task (for example, updating records) on
- a network.
-
- By themselves, the elapsed times reported in these tests are not
- meaningful. They are valuable only when used to compare the
- performances of two or more systems running under near-identical
- conditions. Accordingly, we include the tests run on our
- Editor's Choice configuration of a 3Com 3Server3, 3+Share
- software, and EtherLink interface cards to provide a point of
- comparison. We also show results from a network of Novell's
- Advanced NetWare/286, EtherLink cards, and an IBM PC AT as the
- server. Advanced NetWare is our Editor's Choice for networking
- software, and our tested configuration is a typical one. The
- times are in seconds.
-
-
- Network Speed Under Load Results
-
- Stations 3+Share Advanced Netware/286
- -------- ------- --------------------
- 0 306 264
- 1 423 280
- 2 529 301
- 3 651 310
- 4 761 322
-
-
- Hard Disk Access Load Results
-
- Stations 3+Share Advanced Netware/286
- -------- ------- --------------------
- 0 155 136
- 1 227 150
- 2 330 162
- 3 419 174
- 4 522 182
-
-
- Database Load Results
-
- Stations 3+Share Advanced Netware/286
- -------- ------- --------------------
- 0 155 136
- 1 298 169
- 2 425 212
- 3 585 280
- 4 669 305
-
-
- The Network Speed Under Load and the Hard Disk Access Load
- benchmark tests measure the time needed to perform a standardized
- task on the network. While the actual work loads used for these
- two tests (described below) are different, we used the same
- procedure for both. To obtain the elapsed times shown here, we
- ran a benchmark program performing a sequential create, a
- sequential read, a sequential write, a random read, and a random
- write of a large file. The record sizes used in these activities
- systematically rotate between 16K, 4K, and 512 bytes. The
- numbers shown in the three-dimensional chart are the total time
- necessary for all of these operations. We ran the test on all
- our ATs to load the network while timing just one of them. We
- then reduced the number of workstations one at a time to show the
- effect of loading on the network.
-
- The Network Speed Under Load test puts a heavy load on the
- network interface (cards, media, and so forth) while placing a
- minimal load on the hard disk by having each station continuously
- read and write its own 1-byte data file, changing the data each
- time. For systems with disk caching, the load on the hard disk
- is even smaller, since cached systems typically perform a disk
- write but do not require a physical disk read.
-
- The Hard Disk Access Load test heavily loads the hard disk and
- disk-caching system. To do this, each station randomly accesses
- its own 100K data file using 1K records. Data written to the
- file is changed each time. The random reads typically access
- data outside the cache, which forces a disk read, as does any
- write.
-
- The Database Load test exercises the system's record-locking
- support and the way it handles a number of random simultaneous
- accesses to a common file. This test times how fast each loading
- station accesses a common database consisting of an index and a
- data file. Half the accesses are simple searches of the index
- file and an accompanying access to a record in the data file.
- One quarter of the accesses perform the same operation but also
- lock the data record and update its contents. The remaining
- accesses update the index file and a data record. The index file
- is locked during every update and the DOS 3.1 RLOCK statement
- prevents simultaneous index file updates.
-
-
-
- How to Run the Tests
- --------------------
- The LAN benchmark program uses only DOS 3.x file handling
- facilities and does not require LAN-specific support such as
- NETBIOS support. The test configuration requires at least one
- file server, which can be dedicated or nondedicated. The network
- must also have one or more DOS workstations attached.
-
- The network being tested should be set up and running according
- to the vendor's specifications before the benchmark program is
- run. Each workstation involved in a test should be logged onto
- the network, and the LAN benchmark program must be running on
- each workstation.
-
- Any network options related to file sharing that may be necessary
- for running the benchmark program should be implemented before
- the tests are run. The DOS SHARE program is often required for
- the database load procedure. Also, some systems require special
- attributes to be set for these files. Check the corresponding
- network documentation on file sharing for details.
-
- The LAN benchmark program is menu driven but it does require some
- manual coordination and setup. These options are chosen using
- the setup menu, which creates a setup file--PCMAGLAN.ARG.
-
- The LAN benchmark setup program should be run first. It is
- available from the main menu of the LAN benchmark program. You
- can choose from among various testing parameters--such as the
- file sizes to be used in a test. The setup file should then be
- saved. A single setup file can be shared if the file is
- available on a shared directory on the LAN or individual copies
- can be used on each workstation.
-
- Select a LAN load procedure on each workstation attached to the
- network. These workstations access data on the file server
- attached to the network--and are the cause of the contention for
- processing power. Only one workstation runs a time procedure to
- obtain the final numerical results. Remember to start the load
- procedures before starting the time procedure.
-
- The timed test runs to completion and should not be interrupted.
- It can be terminated using the Control-Break keys, but no results
- will be saved and the test must be restarted completely. The
- load procedures can be incrementally started or stopped while the
- timed test is running without having to restart each load
- procedure from scratch. It is more likely that you will manually
- terminate the load procedures after each portion of the time test
- is completed. The load procedures are interrupted using the Esc
- (escape) key and a prompt will allow the procedure to be
- terminated or to continue.
-
- The load procedures are options 1, 2, and 3 on the main menu.
- Load procedures 1 and 2 use individual and unique files for each
- workstation, and the files can be contained in different
- directories on a shared hard disk. The database load procedure
- uses a common set of files for all load workstations. The files
- used by the load procedures must be contained on the same network
- file server; otherwise, the load procedure may have little or no
- effect on the timed results.
-
- Load procedures 1 and 2 and the timed test automatically create
- their work files and delete them before the procedures terminate.
- Load 3, the database load, requires predefined data files that
- are built using the B option on the main menu. The size of these
- data files is specified in the setup menu. The size of the file
- is specified in terms of levels where smaller numbers equal
- smaller files. The sizes grow exponentially with respect to the
- number of levels.
-
- The timed test is option T on the main menu. It performs
- standard file operations on a single file, including creating the
- file as well as sequential and random reads and writes. The file
- and record sizes can be specified in the setup menu and the
- numbers can have a trailing K or M for kilobytes or megabytes,
- respectively. Record sizes can be in bytes, although the file
- size is rounded up to the nearest kilobyte. Up to eight record
- sizes can be listed and the record sizes are processed in the
- order listed. The test file is deleted after each record size is
- used and a new file is created for each additional record size.
-
- The program provides two result files. One is suitable for
- printing or incorporation into a document using most word
- processors (PCMAGLAN.TXT). The second is formatted for
- spreadsheet programs that can read comma-separated variable (CSV)
- format files (PCMAGLAN.CSV). The numbers saved in the timed test
- result files are identical; only the format is different. The
- LAN benchmark program will append new results to the end of the
- files if they already exist.
-
-
-
- Cleaning Up and Filenames
- -------------------------
-
- Normally the timed procedure and loading procedures delete any
- files they create when the test is done. The exceptions are the
- files created for the database load procedure. These files must
- be deleted manually using the DOS DELETE or ERASE commands.
-
- The names of the work files used by the LAN benchmark program can
- be changed in the setup menu, but the defaults include:
-
- PCMAGLAN.IDX database index file
- PCMAGLAN.DAT database data file
- TMPXXXXX temporary work file
-
- The temporary work-file names actually have the XXXXX replaced by
- a random number so that each file is unique. The temporary work
- files may be accidentally left on the disk if the network or
- program is terminated improperly or prematurely aborted.
- Temporary files will never be used again, so they can be deleted
- at any time. Although the database files can be easily
- reconstructed using the LAN benchmark program, they should be
- deleted only when they are no longer needed.
-
- PCMAGLAN.ARG is a file created from the setup menu. It contains
- the user-defined options. A single copy of PCMAGLAN.ARG can be
- placed on a shared directory on the file server or each
- workstation can have its own copy. PCMAGLAN.ARG is loaded by
- default when the program is started. There is no way to change
- the default filename. However, if you want to rename the file in
- order to save different setups, you can load it explicitly
- through an option found in the main menu. Different setup files
- can be used to save different test parameters, different LAN
- names, and different result-file names.
-
- The setup file PCMAGLAN.ARG does not have to exist for the LAN
- benchmark program to run. Default values are used if there is no
- file.
-
- PCMAGLAN.TXT and PCMAGLAN.CSV are the default names for the
- result files created by the time test. These can be deleted if
- the results are no longer needed or can be saved accordingly.
-
- All filenames can contain drive designations and directory path
- names. This allows more flexible placement of the files and
- allows results to be placed on a drive other than the one being
- tested.
-
- The LAN benchmark program traps some errors, but occasionally
- "disk full" errors or LAN-related errors occur. It is also
- possible to corrupt the LAN benchmark database files. The
- program will detect and report on the latter. It is best to
- delete all temporary and database files and regenerate the
- database if this occurs. The results for any timed test should
- be disregarded if these types of errors occur.
-
- In general, the LAN benchmark program can be aborted using
- Control-Break. Reboot or power-down the workstation if the
- program must be terminated and it does not respond to Control-
- Break.
-
- Be careful when editing and appending time test results. Some
- text editors place an end-of-file character at the end of a file.
- This character is not visible when the file is typed or edited.
- The time test appends data to the physical end-of-file, which may
- appear after this character if the result files are edited and
- saved. The data will be in the file but will not be accessible
- using this type of editor or via the DOS TYPE command. Edit only
- copies of files from the time test to prevent this problem from
- occurring. Also, look at the file size versus the amount of
- information that is viewable to see if this is a problem you may
- have encountered.
-
- Cummulative time test results are appended to the end of a result
- file, not the beginning. This is a useful way of keeping the
- results for different numbers of workstations and different kinds
- of loads.
-
-
- PC Labs Setup
- -------------
-
- The results printed by PC Magazine are obtained by repeating the
- LAN benchmark test using different load procedures and different
- numbers of load workstations.
-
- PC Labs uses standard IBM PC AT computers running at 8 MHz. Six
- ATs are used as workstations and an additional AT is used if a
- dedicated AT server is required. The dedicated AT server is
- augmented with 2MB of extended memory when it is used. The other
- workstations have no extended memory.
-
- One AT is designated as the timed workstation while the others
- are load workstations. The PC Labs configuration is set up in a
- single room so that each workstation is easily viewed at the same
- time.
-
- When PC Labs tests a non-IBM server, the vendor's server replaces
- the AT. Servers are tested as delivered. The LAN is set up
- based upon the vendor's documentation. No tuning is done on the
- server or the workstations other than what is specified in the
- standard installation procedure. All configurations are tested
- using supplied service programs and normal DOS applications to
- make sure the LAN is running properly before the LAN benchmark
- program is run.
-
- How We Interpret Results
- ------------------------
- As described above, the benchmark-test results reported in PC
- Magazine are generated on a standard network configuration.
- Although you can test any LAN using the PC Labs benchmark
- program, results obtained using a LAN configuration different
- from the PC Labs standard configuration cannot be compared with
- results printed in the magazine. The LAN benchmark program tests
- file-access performance only. It does not test other aspects of
- the network such as print spooling, electronic mail,
- communications, or bridges.
-
- The three different load tests come into play as more
- workstations log onto the network. These tests are designed to
- place an unusually heavy and consistent load on the network.
- Bear in mind that the number of workstations a network
- configuration can support is normally much larger than the
- standard PC Labs LAN test configuration.
-
- The Network Speed Under Load test is designed to place a heavy
- load on the network software and transport mechanism. Each
- workstation reads and writes a single-byte file. This should
- generate a minimum amount of disk traffic on the server. In
- fact, some servers with good buffering techniques will perform no
- disk accesses until the tests are done. On the other hand, the
- test should generate a great deal of network traffic. The
- network adapter on the server can be kept at maximum load with a
- sufficient number of workstations.
-
- The Hard Disk Access Load test also generates a good deal of
- network traffic, but it also performs a large number of disk
- operations. The size of the data files used can be specified and
- should be larger than the amount of buffering available on the
- hard disk. The traffic is similar to that encountered when
- copying large amounts of data or when running applications that
- heavily access the file server's hard disk.
-
- The Database Load test uses a common database, which is accessed
- by each load workstation. Record locking is used on the index
- file and data file. Access to the records is random with a
- distribution of data record reads, data record updates, and index
- record updates. The load simulates a heavy access to a common
- database. This would be comparable to a significantly larger
- number of workstations performing query operations to a common
- database. The locking procedures are similar but not identical
- to many commercial network database products. However, the test
- is primarily designed to show how good or bad a network supports
- simultaneous file access with record locking. DOS 3.x file and
- record locking are mandatory for this test.
-
- The time test can be used in conjunction with any other load
- procedures you create. PC Labs tests only the same type of load
- within individual tests for consistency and to simplify
- interpretation of test results. The change in the test results
- shows how much variance may be observed on a heavily loaded or
- heavily populated network.
-
- The time test results can be interpreted in isolation based on
- the nature of the tasks (i.e., network traffic vs. server disk
- access). Results can be compared on the same network with
- varying numbers of workstations logged on (i.e., network
- contention for the same task with three workstations as compared
- with eight). Or you can compare a similar number of workstations
- using the same load but different network configurations (i.e.,
- token-ring vs. star topology).
-
- For example, while write operations normally take longer than
- read operations, the factor will vary depending upon the network
- configuration. Likewise, you can isolate the effect of
- additional buffers on the server, as well as the workstation, by
- changing the setup options and rerunning the tests.